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COMPUTING MACHINE HAVING IMPROVED COMPUTING ARCHITECTURE 
AND RELATED SYSTEM AND METHOD 

Claim of PRroRmr 

11] This application claims priority to U.S. Provisional Application Seriai 

No, 60/422,503. filed on October 31 . 2002, which is Incorporated by reference. 

Cross reference to related applications 

[2| This application is related to U.S. Patent App. Serial Nos. 10/684,102 

entitled IMPROVED COMPUTING ARCHITECTURE AND RELATED SYSTEM AND 
METHOD; 10/683,929 entitled PiPELINE ACCELERATOR FOR IMPROVED 
COMPUTING ARCHITECTURE AND RELATED SYSTEM AND METHOD; 
10/684,057 entitled PROGRAMMABLE CIRCUIT AND RELATED COMPUTING 
MACHINE AND METHOD; and 10/683,932 entitled PIPELINE ACCELERATOR 
HAVING MULTIPLE PiPELINE UNITS AND RELATED COMPUTING MACHINE 
AND METHOD; all filed on October 9, 2003, and having a common owner, and 
which are incorporated by reference. 

Background 

[3] A common computing architecture for processing reiativeiy large 

amounts of data in a relatively short period of time includes multiple interconnected 
processors that share the processing burden. By sharing the processing burden, 
these multiple processors can often process the data more quickly than a single 
processor can for a given clock f requency. For exampie, each of the processors can 
process a respective portion of the data or execute a respective portion of a 
processing algorithm. 

m FIG. 1 1s a schematic block diagram of a conventional computing 

machine iO having a multi-processor architecture. The machine 10 includes a 
master processor 12 and coprocessors f 4-, - f4«, which communicate with each 
other and the master processor via a bus 16, an input port 1S for receiving raw data 
from a remote device (not shown in FIG. 1), and an output port 20 for providing 
processed data to the remote source. The machine 10 also Includes a memory 22 
for the master processor 12, respective memories 24, ~ 24„ for the coprocessors 14i 
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~ 14n, and a memory 26 that the master processor and coprocessors share via the 
bus 16. The memory Z2 serves as both a program and a working memory for the 
master processor 12, and each memory 24i - 24„ serves as both a program and a 
v^orklng memory for a respective coprocessor f 4f ~ f 4„. The shared memory 26 
allows the master processor 12 and the coprocessors 14 to transfer data among 
themselves, and from/to the remote device via the ports 18 and 20, respectiveiy. 
The master processor 12 and the coprocessors 14 also receive a common clock 
signal that controls the speed at which the machine 10 processes the raw data. 

£^ in general, the computing machine 10 effectively divides the 

processing of raw data among the master processor 12 and the coprocessors 14. 
The remote source (not shown in FlO. 1) such as a sonar array loads the raw data 
via the port 18 into a section of the shared memory 26, which acts as a 
first-in-first-out (FiFO) buffer (not shown) for the raw data. The master processor 12 
retrieves the raw data from the memory 26? via the bus 16, and then the master 
processor and the coprocessors 14 process the raw data, transferring data among 
themselves as necessary via the bus 16. The master processor 12 loads the 
processed data into another FiFO buffer (not shown) defined in the shared memory 
26, and the remote source retrieves the processed data from this FIFO via the port 
20, 

C6| In an example of operation, the computing machine 10 processes the 

raw data by sequentially performing n + 1 respective operations on the raw data, 
where these operations together compose a processing algorithm such as a Fast 
Fourier Transform (FFT). More specificaily, the machine 10 forms a data-processing 
pipeline from the master processor 12 and the coprocessors 14. For a given 
frequency of the dock signal, such a pipeline often allows the machine 10 to process 
the raw data faster than a machine having only a single processor. 

173 After retrieving the raw data from the r^w-data FIFO (not shovw) in the 

memory 20, the master processor 12 performs a first operation, such as a 
trigonometric function, on the raw data. This operation yields a first result, which the 
processor 12 stores In a first-result FIFO (not shown) defined within the memory 26. 
Typically, the processor 12 executes a program stored In the memory 22, and 
performs the above-described actions under the contnal of the program. The 



wo 2004/042574 



FCr/US20«3/034559 



processor 12 may also use the memory 22 as working memory to temporarily store 
data that the processor generates at Intermediate intervals of the first operation. 

[83 Next, after retrieving the first resuK from the first-result FIFO (not 

shown) in the memory 26, the coprocessor U-t performs a second operation, such 
5 as a logarithmic function, on the first result. This second operation yields a second 
resuit, whidi the coprocessor f4j stores in a second-result FIFO {not shown) defined 
within the memory 26. Typicaliy, the coprocessor 14i executes a program stored in 
the memory 24i, and performs the above-described actions under the contral of the 
program. TTie coprocessor 14i may also use the memory 24# as working memory to 
1 0 temporarily store data that the coprocessor generates at intermediate intervals of the 
second operation. 

[93 Then, the coprocessors 242 - 24„ secjuentiaily perform third ~ n* 

operations on the second ~ (n~1)"' results in a manner similar to that discussed 
above for the coprocessor 24i. 

15 ("lO] The n* operation, whidi Is performed by the coprocessor 24«, yields 

the final result, /.e., the processed data. The copnocessor 24« loads the processed 
data into a processed-data FIFO (not shown) defined within the memory 26, and the 
remote device (not shown in FIG, 1) retrieves the processed data from this FIFO. 

{1 13 Because the master processor 12 and coprocessors 14 are 

20 simultaneously performing different operations of the processing aigorithm, the 

computing machine 10 Is often able to process the raw data faster than a compu^ng 
machine having a single processor that sequentially performs the different 
operations. Specifically, the single processor cannot retrieve a new set of the raw 
data until it perfonns all n + 1 operations on the previous set of raw data. But using 
25 the pipeline technique discussed above, the master processor 12 can retrieve a new 
set of raw data after performing oniy the first operation. Consequenfiy, for a given 
dock frequency, this pipeline technique can increase the speed at which the 
machine 10 processes the raw data by a fector of approximately n + 1 as compared 
to a single-processor machine (not shown in FIG. 1). 

30 [12] Alternatively, the computing machine 10 may process the raw date in 

parallel by simultaneously performing n + l instances of a processing aigorithm, 

3 
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such as an FFT, on ihe raw data. That is, rf the algortthm includes n + 1 secpientjal 
operations as described above in the previous exampfe, then each of the master 
processor 12 and the coprocessors 14 sequentially perform all n + 1 operations on 
respective sets of the raw data. Consequently, for a given clock frequency, this 
paraitei-piocessing technique, tike the above-described pipeline technique, can 
increase the speed at which the machine 10 processes th© raw data by a factor of 
approximately n + 1 as compared to a single-processor machine (not shown in FIG. 
1). 

[13| Unfortunately, although the computing machine 10 can process data 

more quiddy than a single-processor computer machine (not shown In FIG. 1), the 
dala-processtng speed of the machine 10 Is often significantly less than the 
frequency of the processor clock. Specifically, the data-processing speed of the 
computing machine 10 is limited by the time that the master processor 12 and 
coprocessors 14 require to process data. For brevity, an example of this speed 
limitation is discussed in conjunction with the master processor 12, although it is 
understood that this discussion also applies to the coprocessors 14. As discussed 
above, the master processor f 2 executes a program that controls the processor to 
manipulate data in a desired manner. This program includes a sequence of 
instructions that the processor 12 executes. Unfortunately, the processor 12 
typically requires multipie clock cycles to execute a single instrucifon, and often must 
execute multiple instructions to process a single value of data. For example, 
suppose that the processor 12 is to multiply a first data value A (not shown) by a 
second data value B (not shown). During a first dock cycle, the processor 12 
retrieves a multiply instruction from the memory 22. During second and third clock 
cycles, the processor 12 respectively retrieves A and B ftom the memory 26. During 
a fourth clock cycle, the processor 12 rrojlttpHes A and B, and, during a fifth clock 
cycle, stores the resulting product in the memory 22 or 26 or provides the resulting 
product to the remote device (not shown). This is a best-case scenario, because in 
many cases the processor 12 requires additional clock cycles for overhead tasks 
such as initializing and closing counters. Therefore, at best the processor 12 
requires five clock cycles, or an average of 2.5 clock cycles per data value, to 
process A and B., 
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[14] Consequently, the speed at which the computing machine 10 

processes data fs often signlficantfy lower than the frequency of the dock that drives 
the master processor 12 and the coprocessors 14. For example, If the processor 12 
is docked at 1.0 Gigahertz (GHz) but requires an average of 2.5 clock cycles per 
5 data value, then the effective data-processing speed equals (1 ,0 GHz)/2,5 = 0,4 
GHz. This effective data-processing speed is often characterized in units of 
operations per second. Therefore, in this example, for a dock speed of 1.0 GHz, the 
processor f 2 would be rated with a data-processing speed of 0.4 
Gigaoperations/second (Gops). 

10 £15] FIG. 2 is a bfock diagram of a hardwired data pipeline 30 that can 

typically process data faster than a processor can for a given dock frequency, and 
often at substantially the same rate at which the pipeline Is docked. The pipeline 30 
indudes operator circuits 32f - 32^ that each perfomi a respective operation on 
respective data without executing program instructions. That is. the desired 

15 operation is "burned in" to a circuit 32 such that it implements the operation 

automatically, without the need of program instructions, By eriminating the overhead 
associated with executing program instructions, the pipeline 30 can typically perform 
more operations per second than a processor can for a given dock frequency. 

t1 63 For example, the pipeline 30 can often solve the following equatton 

20 faster than a processor can for a given dock frequency: 

where Xk represents a sequence of raw data values. In this example, the operator 
circuit 32i is a muttipjier that calculates 5xk, the circuit 322 is an adder that calculates 
6Xfe + 3, and the circuit 32„ (n = 3) is a multiplier that cafcuiates {5Xk + 3)2'*\ 

25 11 7] During a first clock cycle k=1 , the circuit 32f receives data value Xi and 

multiplies it by 5 to generate 5xi, 

|18] During a second dock cycle k = 2, the circuit 322 receives 5xi fnam the 

circuit 32* and adds 3 to generate 6xt + 3. Also, during the second dock cyde, the 
circuit 32f generates Sxg. 

[193 During a third dock cycle k = 3, the circuit 32^ receives 5xi + 3 
from the circuit 322 and multiplies by 2*^(ei¥ectlvely left shifts 5xi + 3 by xt) to 

5 
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generate the first result (5xi + 3)2"^^ Also during the third clock cyde, the circuit 32f 
generates Sxa and the cireuR 322 generates Sxa ^ 3. 

|20J The pipeline 30 continues processing subsequent raw data values xk in 

this manner untif all the raw data vaiues are processed. 

5 [21] Consequently, a delay of two clock cycles after receiving a raw data 

vaiue Xi — this delay fs often caHed the latency of the pipeiine 30 — the pipefine 
generates the resuft (5xi 4- 3)2^\ and thereatar generates one result — e.g., (5x2 
3)2"^, (6x3 ^ 3)2''^, , . 5Xn ^ 3)2^'^ — each dock cycle. 

[22] Disregarding the latency^ the pipeline 30 thus has a data-processing 

1 0 Speed equa! to the dock speed. In comparison, assuming that the master processor 
12 and coprocessors 14 (FIG. 1) have data-processing speeds that are 0,4 times the 
ofock speed as In the above example, the pipeline 30 can process data 2,5 times 
faster than the computing machine 10 (FJG. 1) for a given clock speed* 

[231 Still referring to FIG. 2, a designer may choose to imptement the 

15 pipeline 30 in a programmable logic !C (PLJC), such as a fiefd-programmable gate 
array (FPGA), because a PLIC allows more design and modification ftexibility than 
does an application specifiG IC (ASIC), To configure the hardwired connections 
within a PLfC, the designer mereiy sets interconnection-configuration ragisters 
disposed within the PLIC to predetermined binary states. The combination of afl 
20 these binary states Is often called ''firmware/' Typically, the designer ioads this 

flmiware into a nonvolatile memory (not shown in FIG* 2) that is coupled to the PLIC, 
When one "turns on" the PLiC, it downloads the firmware from the memory into the 
interconnec^ion*configuration registers* Therefore, to modify the ftinctloning of the 
PLIC, the designer merely modifies the firmware and allows the PLIC to download 
25 the modified firmware into the interconnection'-conflguration registers. This ability to 
modify the PL!C by merely modifying the firmware is particularly useful during the 
prototyping stage and for upgrading the pipeline 30 In the field", 

p4| Unfbrtunateiy, the hardwired pipeline 30 typically cannot execute all 

algorithms^ particularly those that entail significant decision making. A processor can 
30 typically execute a decision-making instruction {e.g., conditionai instructions such as 
"if A, then go to B, els© go to C") approximately as fast as it can execute an 
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operational instruotton {e.g., "A ^ B") of comparable lengths But afthough the pipeHne 
30 may be able to make a reSatively simple decision (e.g., "A > B?"), it typiGally 
cannot execute a relatively compiex decision {e.g., If A, then go to B, else go to C"). 
And although one may be able to design the pipaiine 30 to execute such a compiex 
5 decision, the size and compiexity of the required circuitry often makes such a design 
impracticai, particulariy v^here an algorithm includes multiple diHerer^t complex 
decisions. 

[253 Consequentfy, processors are typically used fn applications that require 

significant decision making, and hardwired pipelines are typicaiiy limited to "number 
1 0 crunching" applications that entail little or no decision making* 

{261 Furthermore, as discussed below, it is typicaiiy much easier for one to 

design/modify a processor-based computing machine, such as the computing 
machine 10 of FtG* 1, than it is to design/modify a hardwired pipeline such as the 
pipeline 30 of FIG- 2, particularly where the pipeline 30 inciudes multiple PLfCs, 

1 5 £273 Computing components, such as processors and their peripherals 

(e,gf., memory), typically Include Industry-standard communication interfaces that 
faciiitate the fnterconnection of the components to form a processor-based 
computing machine. 

[28] Typically, a standard communication interface includes tv^^o layers: a 

20 physical layer and a service layer. 

[293 The physical layer includes the circuitry and the conresponding circuit 

interconnections that form the interface and the operating parameters of this 
circuitry. For example, the physical layer Indudes the pins that connect the 
component to a bus. the buffers that latch data received from the pins, and the 
25 drivers that drive data onto the pins. The operating parameters include the 

acceptable voltage range of the data signals that the pins receive, the signa! timing 
for writing and reading data, and the supported modes of operation (e.g., burst 
mode, page mode). Conventional physical layers include transistor-transistor logic 
(TIL) and RAMBUS, 

30 f;303 The service layer includes the protocol by which a computing 

component transfers data. The protocol defines the format of the data and the 
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manner in which the component sends and receives Vne formatted data. 
Conventional communication pmtocols include file-transfer' protocol (FTP) and 
TCP/IP (expand). 

[31 J Consequently, because manufecturers and others typically design 

computing components having Indus^y-standard communication interfaces, one can 
typically design the interface of such a component and Interconnect It to other 
computing components with relatively little effort. This ailows one to devote most of 
his time to designing the other portions of the computing machine, and to easily 
modify the machine by adding or removing components. 

132] Designing a computing component that supports an industry-standard 

communicatton interface allows one to save design time by using an existing 
physicai-layer design from a design library. This also insures that he/she can easily 
interface the component to off-the-shelf computing components. 

£331 And designing a computing machine using computing components that 

support a ODmmon Industry-standard communication interface allows the designer to 
interconnect the components with little time and effort. Because the components 
suppxsrt a common interface, the designer can intercdnnact them via a system bus 
with litae design effort. And because the supported Interface is an Industry standaixJ, 
one can easily modHy the machine. For example, one can add different components 
and peripherals to the machine as the system design evolves, or can easily 
add/design next-generation components as the technology evolves. Furthermore, 
because the components support a common industry-standard service layer, one 
can Incorporate Into the computing machine's software an existing software module 
that implements the corresponding protocol. Therefore, one can interface the 
components with little effort because the interface design is essentially already in 
place, and thus can focus on designing the portions (0,g„ software) of the machine 
that cause the machine to perfomi the desired functjon(s). 

C343 But unfortunately, ther^ are no known industry-standard 

communication interfaces for components, such as PLICs, used to form hardwired 
pipelines such as tJie pipeline 30 of FIG. 2. 
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Casj Consequently, to design a pipeiln© having multiple PLiCs, one typically 

spends a significant amount of time and exerts a significant effort designing and 
debugging the communicatfon interface between the PLJCs "from scratch." 
Typrcaliy, such an ad hoc communication interface depends on the parameters of 
6 the data being transferred between the PLICs, Lii<ewise, to design a pipeline that 
interfaces to a processor, one would have to spend a significant amount of time and 
exert a significant effort in designing and debugging the communication interface 
between the pipeline and the processor from scratch, 

[36J Simiiariy, to modify such a pipeline by adding a PLIC to it, one typically 

1 0 spends a significant amount of time and exerts a significant effort designing and 
debugging the communication interface between the added PLIC and the existing 
PLICs. Likewise, to modify a pipeline by adding a processor, or to modify a 
computing machine by adding a pipeiine, one would have to spend a significant 
amount of time and exert a significant effort in designing and debugging the 
15 communication interface between the pipeline and processor. 

f37J Consequently, referring to FIGS. 1 and 2, because of tie difficulties In 

interfacing multiple PLICs and in interfacing a processor to a pipeline, one Is often 
forced to make s^niftcant tradeoffs when designing a computing machine. For 
example, with a processor-based computing machine, one Is forced to trade number- 

20 crunching speed and deslgn/modHication flexibility for complex decision-making 
ability. Conversely, with a hardwired pipeline-based computing machine, one is 
forced to trade complex-dectsion-making ability and design/modification flexibility for 
number-crunching speed, Furthemiore, because of the difficulties In interfacing 
multiple PLICs, it is often impractical for one to design a pipeline-based machine 

25 having more than a few PLICs. As a result, a practical pipeline-based machine often 
has limited functionality. And because of the difficulties in interfacing a processor to 
■ a PLIC, it would be impractical to intesface a processor to more than one PLIC. As a 
result, the benefits obtained by combining a processor and a pipeline would be 
minimal. 

30 t38J Therefore, a need has arisen for a new computing architecture that 

allows one to combine the decision-making ability of a processor-based machine 
with the number-crunching speed of a hardwired-plpellne-based machine. 

9 



wo 20iN/<>42574 



FCr/US2WM)3455»> 



[393 in an embodiment of the invention, a computing machine Includes a 

first buffer and a processor coupled to the buffer. The processor is opera bfe to 
execute an appfication, a first data-transfer object, and a second data-transfer object, 
piibHsh data under the control of the application, load the published data Into the 
buffer under the control of the first data-transfer object, and retrieve the published 
data from the buffer under the controi of the second data-transfer object 

J40| AccoftJing to another embodiment of the invention, the processor is 

operable to retrieve data and load the retrieved data Into the buffer under the control 
of the first data-transfer object, unioad the data from the buffer under the control of 
the second data-transfer object, and process the unloaded data under the control of 
the appiicatfon. 

C41] Where the computing machine is a peer-vector machine that includes a 

hardwired pipeline acceierator coupled to the processor, the buffer and data-transfer 
objects facilitate the transfer of data ~ whether unidirectional or bidirectional ^ 
between the application and the accelerator. 

Brief D escription of the Drawings 

[42] FIG. 1 is a block diagram of a computing machine having a 

conventional multiprocessor architecture. 

[43] FIG. 2 Is a block diagram of a conventiona} hardwired pipeilne. 

[44] FIG. 3 18 schematic block diagram of a computing machine having a 

peer-vector architecture according to an embodiment of the invention. 

[45i FIG. 4 is a functional block diagram of the host processor of FIG« 3 

according to an embodiment of the invention^ 

146] FIG. 5 is a funotionai biock diagram of the data-transfer paths between 

the data-processing application and the pipeline bus of FIG. 4 according to an 
embodiment of the invention, 

147] FIG, 6 Is a functional block diagram of the data-transfer paths between 

the accelerator exception manager and the pipeline bus of FIG. 4 according to an 
embodiment of the invention. 

10 
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[48] FIG, 7 is a ftinc^ional block diagram of the data-transfer paths between 

the acceisrator configuration manager and the pipeline bus of FIG- 4 according to an 
embodiment of the Invention, 

DETAitso Description 

[49| FJG. 3 is a schematic biock diagram of a computing machine 40, which 

has a peer-vector architecture according to an embodiment of the invention, in 
addition to a host processor 42, the peer-vector machine 40 includes a pipeline 
accelerator 44. which performs at least a portion of the data processing, and which 
thus effectively replaces the bank of coprocessors 14 in the computing machine iO 
of FJG. 1 . Therefore, the host-processor 42 and the aocelerator 44 are "peers" that 
can transfer data vectors back and forth. Because the acceierator 44 does not 
execute program instructions, it typically perfonns mathematically intensive 
operations on data significantly faster than a bank of coprocessors can for a given 
clock frequency. Consequently, by combing the decision-making ability ofihe 
processor 42 and the number-crunching ability of the acceierator 44, the machine 40 
has th& same abilities as, but can oft&n process data fester than, a conventicmal 
computing machine such as ttie machine 10. Furthermore, as discussed below and 
in previously cited U,S, Pateni App. Serial No. 10/683,929 entitled PIPELINE 
ACCELERATOR FOR IMPROVED COMPUTING ARCHITECTURE AND RELATED 
SYSTEM AND METHOD, providing the accelerator 44 with the same communication 
interface as the host processor 42 facilitates the des^n and modification of the 
machine 40, particularly where the communications Interface is an industry standard. 
And where the accelerator 44 indudes multiple components (e.g., PLtCs), providing 
these components with this same communication interface facilitates the design and 
modification of the acceierator, particufariy where the communication interface is an 
industry standard, yoreover, the machine 40 may also provide other advantages as 
described below and in the previously cited patent applications. 

[50| Still referring to FIG. 3, In addition to the host processor 42 and the 

pipeline accelerator 44, the peer-vector computing machine 40 includes a processor 
memory 40, an Interface niemory 48, a bus 50, a fimnware memory 52, optional raw- 
data input ports 54 and 56, processed-data output ports 58 and SO, and an optional 
router 61. 

11 
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[511 The host processor 42 inciudes a processing unit 62 and a message 

handler 64, and the processor memory 46 Includes a processing-unit memory 06 
and a handler memory 68, which respectively serve as both program and working 
memories for t>e processor unit and the message handler. The processor memory 
40 also includes an accelerator-configuration registry 70 and a 
message-configuration registry 72, which store respectiye configuration data that 
ailow the host processor 42 to configure the functioning of the accelerator 44 and the 
structure of the messages that the message handier 64 sends and receives. 

[52} The pipeline accelerator 44 is disposed on at least one PLfC (not 

shown) and Includes handvwred pipelines 74^- 74„, which process respective data 
without executing program InstrudSons, The firmware memory 52 stores tile 
configuration firmware for the accelerator 44. If the accelerator 44 is disposed on 
multiple PLICs, these PLICs and their respective firmware memories may be 
disposed on multiple circuit boards, i.e., daughter cards (not shown). The 
accelerator 44 and daughter cards are discussed further in previously cited U.S, 
Patent App. Serial Nos. 10/683,929 entitled PIPELINE ACCELEF?ATOR FOR 
IMPROVED COMPUTING ARCHfTECTURE AND RELATED SYSTEM AND 
METHOD and 10/683.932 entitled Pi PELiNE ACCELERATOR HAVING MULTIPLE 
PIPELINE UNITS AND RELATED COMPUTING MACHINE AND METHOD. 
Afternattvely, the accelerator 44 may be disposed on at least one ASIC, and thus 
may have internal interconnections that are unconfigumble. In this alternative, the 
machine 40 may omit the fimrware memory 52. Furtiiermore, although the 
accelerator 44 is shown Including multiple pipelines 74, it may Include only a single 
pipeline. In addition, although not shown, the accelerator 44 may include one or 
more processors such as a digital-signal processor (DSP). 

[53] The general operation of the peer-vector machine 40 Is discussed in 

previously cited U.S. Patent App. Serial No. 10/684,102 entitled IMPROVED 
COMPUTfNG ARCHITECTURE AND RELATED SYSTEiW AND METHOD, and the 
functional topology and operation of the host processor 42 is discussed below in 
conjunction with FiGS. 4 - 7. FIG. 4 Is a functional block diagram of the host 
processor 42 and the pipeline bus 50 of FIG. 3 according to an embodiment of the 
invention. Generally, the processing unit 62 executes one or more software 
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applications, and the message handler 64 executes one or more software objects 
that transfer data between the software application(s) md the pipeline acceterator 44 
(FIG. 3). Splitting the data-processing, data-transferring, and other functions among 
different applications and objects allows for easier design and modification of the 
host-processor software. Furthermore, although in the folfowtng description a 
software application is described as performing a particular operation, it is 
understood that in actual operation, the processing unit 62 or message handler 64 
executes the software application and perfomis this operation under the control of 
the application. Likewse, although In the following description a software ob|ect Is 
described as performing a pai^oilar operation, it is understood that in acfejal 
operation, the processing unit 62 or message handler 04 executes the software 
object and performs this operation under the control of the obfect. 

[54] Stlli referring to FIG. 4, the processing unit 62 executes a 

data-processing application SO, an accelerator exception manager application 
{hereinafter the exception manager) 82, and an accelerator configuration manager 
application (hereinafter the configuration manager) 84, which are coiiectively referred 
to as the processing-unit applications. The data-processing application processes 
data in cooperation with the pipeline accelerator 44 (FIG, 3). For example, the data- 
processing application 80 may receive raw sonar data via 1A\e port 54 (FIG, 3), parse 
the data, and send the parsed data to the accelerator 44, and the accelerator may 
perform an FFT on the parsed data and return me processed data to the data- 
processing application for further proc^sing. The exception manager 82 handles 
exception messages from the acceterator 44, and the configuration manager 84 
loads the accelerator's configuration firmware into the memory 52 during Initialization 
of the peer-vector machine 40 (FIG. 3). The configuration manager 84 may also 
reconfigure the accelerator 44 after initialization in response to, e.g., a malfund;ion of 
the accelerator. As discussed ftirther below m conjunction with FIGS. 6-7, the 
processing-unit applications may communicate with each other directSy as indicated 
by the dashed lines 85, 87, and 89, or may communicate with each other via the 
data-transfer objects 86. The message handier 64 executes the data-transfer 
objects 86, a communication object 88, and input and output read objects 90 and 92, 
and may execute input and output queue objects 94 and 96, The data-transfer 
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objects 80 transfer data between the communication object 88 and tiie 
processing-unit appiications, and may use the Intefface memory 48 as a data buffer 
to allow the processing-unit applications and the accelerator 44 to operate 
independently. For example, the memory 48 allows the accelerator 44, which is 
often faster than the data-processing appiication SO, to operate without ''waiting" for 
the data-processing application. The communfcation object 8S transfers data 
between the data objects 86 and the pipeline bus SO. The input and output read 
objects 90 and 92 control the data-transfer objects 86 as they transfer data between 
the communication object 88 and the processing-unit applications. And, when 
executed, the input and output queue objects 94 and 96 cause the Input and output 
read objects 90 and 52 to synchronize this transfer of data according to a desired 
priority 

155] Furthermore, during Initialization of the peer-vector machine 40 (FIG. 

3), the message handier 64 Instantiates and executes a conventional object factory 
98, which instantiates the data-transfer objects 86 from configuration data stored in 
the message-configuration registry 72 (FIG. 3). The message handler 64 also 
instantiates the communication object 88, the input and output reader objects 90 and 
92, and the input and output queue objects 94 and 96 from the configuration data 
stored in the message-configuration registry 72. Consequently, one can design and 
modify these software objects, and thus their data-transfer parameters, by merely 
designing or modifying the configuration data stored in the registry 72. This is 
typically less time consuming than designing or modifying each software object 
Individually, 

[563 The operation of the host processor 42 of FIG. 4 Is discussed below in 

conjunction vwth FIGS. 5-7. 

Data Processi nt| 

[57j FIG. 5 is a functionai block diagram of the data-processing appiication 

SO, the data-transfer objects 06, and the interface memory 48 of FIG. 4 according to 
an embodiment of IJie Invention. 

[58] The data-processing application 80 includes a number of threads f 00/ 

-- tOOfl, which each perform a respective data-processing operation. For example, 
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the thread iOOi may perfoim an addition, and the thmad lOOz may perform a 
subtraction, or both the threads 100i and 1002 may perfomi an addition. 

[59] Each thread 100 generates, Le., publishes, data destined for the 

pipeline aoceierator 44 (FiG, 3), receives, i.e., subscribes to, data from the 
accelerator, or both publishes and subscribes to data. For example, each of the 
threads IOOi - IOO4 both publish and subscribe to data from the accelerator 44. A 
thread 100 may also cOTmnunicate directly with ancrther thread 100. For example, as 
indicated by the dashed line 102, the threads IOO3 and IOO4 may directly 
communicate with each other. Furthemiore, a thread 100 may receive data from or 
send data to a component (not shown) other than the accelerator 44 (FIG. 3). But 
for bre\rfty, discussion of data transfer between the tiireads 100 and such another 
component fs omitted. 

[601 Stfil referring to FIG, 5, the interface memory 48 and the data-transfer 

objects 86ia - 86„t, functionally form a number of unidirectionai channels 104i ~ 104n 
for transferring data between the respective threads 100 and the communication 
object 8B. The interface memory 48 includes a number of buffers IO61 - 10e„, one 
buffer per channel 104. The buffers 106 may each hold a single grouping (e.g., byte, 
word, block) of data, or at least some of the IxifTers may be FIFO buffers that can 
each store respective multiple groupings of data. There are also two data objects 86 
per channel 104, one for transferring data between a respedlve thread 100 and a 
respective buffer 106, and tie other for transfem'ng data between the buffer 106 and 
the communication object 88. For example, the channel 104t Includes a buffer 106i, 
a data-transfer object 86ia fbr transfemng published data from the thread fOOf to the 
buffer 106i, and a data-transfer object S6it, for transferring the published data from 
the buffer 106i to the communication object 88. Including a respective channel 104 
for each allowable data transfer reduces the potential for data bottlenecks and also 
facilitates the design and modification of the host processor 42 (FIG. 4). 

[613 Referring to FIGS. 3 - 5, the operation of the host processor 42 during 

its initialization and while executing the data-processing application 80, the 
data-transfer objects 86, the communication object 88, and the optional reader and 
queue objects 00, 92, 94, and 9$ is discussed according to an ^tx>diment of the 
invention. 
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[62] During initialization of th© host processor 42, the object factory 9B 

instantiates the data-transfer objects S6 and defines the buffers f (J4. SpectficaHy, 
the object factory 98 downioads the configuration data irom the registry 72 and 
generates the software code for each data-transfer object 86xb that the 
data-processing apptication 80 may need. The identity of the data-transfer objects 
86xb that the application 80 may need is typically part of the configuration data — the 
application 80, however, need not use all of the data-transfer objects 86. Then, from 
the generated objects 86xb, the object factory 98 respectively instantiates iJie data 
objects 86xa. Typicaily, as discussed in the example below, the object factory 9B 
instantiates data-transfer objects 86xa and eSxb that access the same buffer 104 as 
multiple instances of the same software code. This reduces the amount of code that 
th© object factory 98 would otherwise generate by approximately one half. 
Furthermore, ttie message handler 64 may determine which, if any, data-transfer 
objects 86 the appilcaSon SO does not need, and delete the instances of ttiese 
unneeded data-transfer objects to save memory. Alternatively, the message handler 
64 may make this determination before the object factory 98 generates the 
data-transfer objects 86, and cause the object factory to instantiate only the 
data-transfer objecte that the appllcalHon 80 needs, in addition, because the 
data-transfer objecte 86 include the addresses of the interface memory 48 where the 
respective buffers 104 are located, the object factory 98 effectively defines the sizes 
and locations of the buffers when it instantiates the data-transfer objects, 

[63J For example, the object factory 98 instantiates the data-transfer 

objects aSfa and 86ib in the following manner. First, the factory 98 downloads the 
configuration data from the r^istry 72 and generates the common software code for 
tiie data-transfer object 86ia and 86ib. Mext, the factory 98 Instantrates the 
data-transfer objects 86fa and 86ib as respective instances of the common software 
code. That is, the message handler 64 effectively copies the cc^nmon software code 
to two locaticsns of the handler memory 68 or to other program memory {not shown), 
and executes one location as the object 86ia and the other location as the object 
86ib. 
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[643 Still refen-Ing to FIGS- 3-5, after initialization of the host processor 42, 

the data-processing applicatfon 80 processes data and sends data to and receives 
data from the pipeline accelerator 44. 

iQ5} An example of the data-processing application 80 sending daite to the 

accelerator 44 is discussed in conjunction with the diannei 104i, 

1663 First, the thread lOOi generates and publishes data to the data-transfer 

object 8$ia, The thread fOOi may generate the data by operating on mw data that it 
receives from the accelerator 44 (further discussed below) or from another source 
(not shown) such as a sonar array or a data base via the port 54. 

I67J Then, the data-object SSn, loads the published data Into the buffer 

i08i, 

[681 Next, the data-transfer object 86«, determines that the buffer 106i has 

been loaded with newly published data from the data-transfer object 86ia. The 
output reader object 92 may periodically instruct the data-transfer object $eit> to 
check the buffer lOOi for newly published data. Aiternatively, the output reader 
object 92 notifies the data-transfer object SS^a when the buffer 106i has received 
newly published data. Specifically, the output queue object 96 generates and stores 
a unique identifier (not shown) in response to the data-transfer object 86^^ storing the 
published data in the buffer 106i. In response to this identifier, the output reader 
object 92 notifies the data-transfer object 86i^ that the buffer 106i contains newly 
published data. Where multiple buffers 10$ contain respective newly published data, 
then the output queue object 96 may record the order in which this data was 
published, and the output reader object 92 may no% the respective data-transfer 
objects 88xb in the same order. Thus, the output reader object 92 and the output 
queue object 98 synchronize the data transfer by causing the first data published to 
be the first data that the respective data-transfer object 86xb sends to the accelerator 
44, the second data jHjblished to be the second date that the respective data- 
transfer object aSx* sends to the accelerator, etc. In another alternative where 
multiple buffers 108 contain respective newly published data, the output reader and 
output queue objects 92 and 96 may implement a priority scheme other than, or in 
addition to, this first-ln-flrst-out scheme. For example, suppose the thread lOOi 
publishes first data, and subsequently the thread lOOz publishes second data but 
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also publishes to the output queue object 06 a priority flag associated with the 
second data. Because the second data has priority over the first data, the output 

reader object 92 notifies the data»transfer object 862b of the pubiished second data in 
the buffer IO62 before notifying the data-transfer object 86-?^ of the pybiished first 
5 data in the buffer f 06t. 

[893 Then, the data4ransler object 86it retrieves the published data from; 

the buffer 106i and fonmats the data in a predetermined manner. For example, the 
object 86ii9 generates a message that includes flie published data {Lb., the paytoad) 
and a header that, e.g., identifies the destination of the data within the accelerator 
10 44. This message may have an industry-standard format such as the Rapid JO 

(input/output) format Because the generation of such a message is conventional, it 
IS not discussed further. 

[70] After the data-transfer object 86ii, formats the published data, it sends 

the formatted data to the communication object 88. 

1 5 [713 Next, the communication object 88 sends the formatted data to the 

pipeline accelerator 44 via the bus 50. The communioation object 88 is designed to 
implement the communteation protocol (e.g.. Rapid lO, TCP/IP) used to transfer data 
between the host processor 42 and the accelerBtor 44. For example, the 
communication object 88 implements the required hand shaking and other transfer 

20 parameters (e.g., arbitrating the sending and receiving of messages on the bus 50) 
that the protocol requires. Alternatively, the data-transfer object S6xb can implement 
the communiGation protocoi, and the conimunicatbn object 88 can be omitted. 
However, this latter aiternative is less efficient because it requires all the data- 
transfer objects 88xb to include additional code and functionality^ 

25 [72] The pipeline acceierafor 44 then receives the formatted data, recovers 

the data from the message (e.g., separates the data from the header if there is a 
header), directs the data to the proper destination within the accelerator, and 
processes the data. 

[73] Stiii referring to FIGS, an example of the pipefine accelerator 44 

30 (FIG, 3) sending data to the host processor 42 (FIG. 3) ts discussed in conjunction 
with the channel 1942^ 
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[74] First, the pipefine acceierator 44 generates and formats data. For 

example, the acceferator 44 generates a message that Includes the data payfoad 
and a header that, e.g., fdentifies the destination threads lOOi and IOO2, which are 
the threads that are to receive and process the data. As discussed above, this 
5 message may have an industry-standard format such as the Rapid lO (input/output) 
format. 

t75J Next, the accelerator 44 dnves the formatted data onto the bus 50 m a 

conventlonat manner 

[76] Then, the communication object 88 receives the formatted data from 

1 0 the bus 50 and provides the formatted data to the data-transfer object S^zb^ in one 
embodiment tha formatted data is in the form of a message, and the communication 
object 88 analyzes the message header (which, as discussed above, identifies the 
destination threads lOOi and IOO2) and provides the message to the data-transfer 
object SBzt in response to the header. !n another embodiment, the communication 
1 5 object 88 provides the message to all of the data-transfer objects S6»fc, each of which 
anafyzes the message header and processes the message only if its function is to 
provide data to the destination threads iOOf and f Consequently, in this 
example, only the data-transfer obiect 862b processes the message, 

|77| Next, ttie data-transfer object 862t loads the data received from the 

20 communicatfon object 88 into the buffer 1062^ For example, if the data is contained 
within a message payioad, the data-transfer object 862^$ recovers the data from the 
message {e.g., by stripping the header) and loads the recovered data into the 
buffer 106z. 

|78] Then, the data-transfer object 862^ determines that the buffer IO62 has 

25 received new data from the data-transfer object SS^fo. The Input reader object 90 
may periodicaHy instruct the data-transfer object 88za to check the buffer IO62 for 
newly received data. Alternatively, the input reader object 90 notrfies the 
data-transfer object 882^ when the buffer IO62 has received newly published data, 
Speciflcaily, the input queue object 94 generates and stores a unique Identifier (not 
30 shown) in response to the data-transfer object 862b storing the published data in the 
buffer 1062' in response to this identifier, the input reader object 90 notifies the 
data-transfer object 862a that the buffer iOSz contains newiy pubOshed data. As 
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discussed above in conjunction with the output reader and output queue objects 02 
and 96, where muitipfe buffers f 06 contain respective newiy published data, then the 
Input queue object 94 may record the order in which this data was pubfished, and the 
input reader object 90 may notify the respective data4ransfer objects 86^a lr\ the 
same order> Alternatively, where multiple buffers f 06 contain respective newly 
published data, the input reader and input queue objects 90 and 94 may implement a 
priority scheme other than, or in addition to, this first4n'4^irst-oyt scheme. 

[791 Next, the data-ob|act SSz^ transfers the data from the buffer IO62 to the 

subscriber threads iOOi and IOO2, which perform respective operations on the data, 

|S0] Referring to FIG. S, an example of one thread receiving and processing 

data from another thread is discussed in conjunction with the thread IOO4 receiving 
and processing data published by the thread f OO3. 

£81 1 in one embodiment the thread f OO5 publishes the data directly to the 

thread IOO4 via the optional conneoHon (dashed line) 102. 

|82] fn another embodiment, the thread f OO3 publishes the data to the 

thread fOO^ vfa the channels 104$ and 104e. Spedficaliy, the data^ransfar obfect 
86s^ loads the published data into the buffer f 0% Next, the data-transfer object 86$^ 
retrieves the data from the buffer IO65 and transfers the data to the communication 
ob|ect 88, which publishes the data to the data-transfer object 86m* Then, the 
data-transfer object 86et loads the data into the buffer 106ei Next, the data»transfer 
object 88ea transfers the data from the buffer 106^ to the thread IOO4. Alternativeiy, 
because the data is not being transferred via the bus 50, then one may modify the 
data-transfer object SSsb such that it toads the data directly into the buffer f 06^, thus 
bypassing the communication object 88 and the data-transfer object 864^^- But 
modifying the data-transfer object 8Ssi, to be different from the other data-transfer 
objects 86 may increase the complexity modularity of the message handler 64. 

[831 Stm referring to FIG. 5, additional data-transfer techniques are 

contemplated. For exampie a single thread may publish data to multiple iocations 
within the pipeline accelerator 44 (FIG. 3) via respective multipie channels. 
Afternatfvefy, as discussed in previousiy cited U.S. Patent App. Serial Nos, 
10/684,102 entitled IMPROVED COIVlPUTtNG ARCHITECTURE AND RELATED 
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SYSTEM AND METHOD and 10/683,929 entitled PIPELINE ACCELERATOR FOR 
IMPROVED COMPUTING ARCHITECTURE AND RELATED SYSTEM AND 
METHOD, the accelerator 44 may receive data \iia a single channel i04 and pxo\AdB 
it to multiple locations vwthin the accelerator. Furthermore, multiple threads {e.g., 
threads 100i and lOQz) may subscribe to data from the same channel (e.g., channel 
iOAz). in addition, multiple threads {e.g., threads iOOz and 100^) may publish data to 
the same location within the accelerator 44 via the same channel {e.g., channel 
1043)r although the threads may publish data to the same accelerator location via 
respective channels i04. 

|843 FIG. 6 Is a ftrnctional block diagram of the exception manager $2, the 

data-transfer objects B6, and the interface memory 4B according to an embodiment 
of the invention. 

£85| The exception manager 82 receives and logs exceptions that may 

occur during the initialization or operation of the pipeline accelerator 44 (FIG. 3). 
Generaily, an exception is a designer-defined event where the accelerator 44 acts in 
an undesired manner. For example, a buffer (not shown) that overflows may be an 
exception, and thus cause the accelerator 44 to generate an exception message and 
send it to the exception manager 82. Generation of an exception message is 
discussed in previously cited U.S. Patent App. Serial No, 1 0/683,929 entitJed 
PIPELINE ACCELERATOR FOR IMPROVED COMPUTING ARCHITECTURE AND 
RELATED SYSTEM AND METHOD. 

[86] The exception manager 82 may also handie exceptions that occur 

during the initialization or operation of the pipeline accelerator 44 (FIG. 3). For 
example, if the accelerator 44 includes a buffer (not shown) that overflows, then the 
exception manager 82 may cause the accelerator to increase the size of the buffer to 
prevent future overflow. Or, if a section of the accelerator 44 malfunctions, the 
exception manager 82 may cause another section of the accelerator or the 
data-processing application 80 to perfomi the operation that the malfunctioning 
section was intended to perform. Such exception handling is furth^ discussed 
below and in previously cited U.S. Patent App. Serial No. 10/;683,929 entitled 
PIPELINE ACCELERATOR FOR IMPROVED COMPUTING ARCHITECTURE AND 
RELATED SYSTEM AND METHOD. 
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£87] To log and/or handle accelerator exceptions, the exception manager B2 

subscribes to data from one or mofB subscriber threads 100 {FIG. 5) and determines 
from this data whether an exception has occurred. 

[S81 In one aiternative, the exception manager 82 subscribes to the same 

5 data as the subscriber threads 100 (FiG. 5) subscribe to. Spedflcaily, the manager 
82 receives this data via the same respective channels 104s {which include, e.g., 
channel 1042 of FiG. 5) from which the subscriber threads 100 (which include, e.g., 
threads lOOi and IOO2 of PIG. 5) receive the data. Consequently, the channels 104^ 
provide this data to the exception manager 82 in the same manner that they provide 
0 this data to the subscriber threads 100. 

189} In another alternative, the exception manager 82 subscribes to data 

from dedicated channels 106 (not shown), which may receive data from sectrons of 
the accelerator 44 (FIG. 3) that do not provide data to the threads 100 via the 
subscriber channels 104s. Where such dedicated channels 104 are used, the object 
5 factory 98 (FIG. 4) generates the data-transfer objects 86 for these channels during 
initialization of the host processor 42 as discussed above in conjunction with FIG. 4. 
The exception manager 82 may subscribe to the dedicated channels 106 exclusively 
or in addition to the subscriber channels 104^. 

[90] To determine whether an exception has occurred, the exception 

manager 82 compares the data to exception codes stored in a registry (not shown) 
within the memory 66 (FIG. 3). If the data matches one of the codes, then the 
exception manager 82 determines tfiat the exception corresponding to the matched 
code has occurred. 

[91] In another alternative, the exception manager 82 analyzes the data to 

determine If an exception has occurred. For example, the data may represent the 
result of an operation peribrmed by the accelerator 44. The exception manager 82 
detenmines whether the data contains an error, and, if so. determines that an 
exception has occun-ed and the id&nm>/ of the exception. 

[92] After detennlning that an exception has occurred, the exception 

manager S2 fogs, e.g., the corresponding exception code and the time of 
occurrence, for later use such as during a debug of the accelerator 44. The 
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exception manager 82 may also determine and convey the identity of the exertion 
to, e.g., the system designer, in a conventional manner. 

[931 Alternatively, in addition to logging the exception, the exception 

manager 82 may implement an appropriate procedure for handling the exception. 
For example, the exception manager 82 may handle the exception by sending an 
exception-handling instmction to the accelerator 44, the data-processing application 
80, or the configuration manager 84. The exception manager 82 may send the 
exception-handling instruction to the accelerator 44 either via the same respective 
channels 104p (e.g., channel 104i of FIG. 5) through which the publisher threads 100 
(e.g., thread of FIG. 5) publish data, or through dedicated exception-handling 
channels 104 (not shown) that operate as described above in conjuncflon with FIG. 
5. If the exception manager 82 sends instructions via other channels 104, then itie 
object fectory 98 (FIG. 4) generates the data-transfer objects 86 for these channels 
during initialization of the host processor 42 as described above in conjynction with 
FIG. 4. The exception manager 82 may publish exception-handling instructions to 
the data-processing application 80 and to the configuration manager 84 either 
directly (as indicated fay the dashed lines 85 and 89 in FIG. 4) or via the 
Channels 104apai and 104dpi,z (appilcation 80) and channels 104cmi and 104cm2 
(configuration manager 84), which the object factory 08 also generates during the 
initialization of the host processor 42. 

[94] Still referring to FIG, 6, as discussed below the exception-handling 

instructions may cause the accelerator 44, data-processing application 80, or 
configuradon manager 84 to handle the coiresponding exception in a variety of 

[953 When sent to the accelerator 44, the exception-handling instruction 

may change the soft configuration or the ftinctioning of the accelerator. For 
example, as discussed above, if the exception Is a buffer overHow, the instruction 
may change the accelerator's soft configuration (/.©., by changing the contents of a 
soft configuration register) to increase the size of the buffer. Or, if a section of tie 
aojelerator 44 that perfonms a particular operation Is malibnctloning, the instniction 
may change the accelerator's functioning by causing the accelerator to take the 
disabled section "off line." In this latter case, the exception manager 82 may, via 
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addfttonal instructions, cause another section of the accelerator 44, or the 
data-processing applieatlon 80, to take over" the operation from the disabled 
accelerator secdon as discussed below. Altering the soft configuration of the 
accelerator 44 is further discussed In previously cited U.S. Patent App, Serial Ho. 
10/683,929 entitled PIPELINE ACCELERATOR FOR iMPROVED COMPUTiNG 
ARCHITECTURE AND RELATED SYSTEM AND METHOD (Attorney Docket No. 
1934-13-3). 

[96| When sent to the data-processing application 80, the 

exception-handling instructions may cause ttie data-processing application to "ta!<e 
over" the operation of a disabled sectbn of the accelerator 44 that has been taken 
off line. Although the processing unit 62 <FI6. 3) nnay perfbnn this operation nnore 
slovsrty and less efficientiy than the accelerator 44, this may be preferable to not 
performing the operation at all. This ability to shift the performance of an operation 
from the accelerator 44 to the processing unit 62 increases the fiexibility, reliability, 
maintainability, and fault-tolerance of the peer-vector machine 40 (FIG. 3). 

t973 And when sent to the configuration manager 84, the 

exception-handling Instruction may cause the configuration manager to change 8ie 
hand configuration of the accelerator 44 so that the accelemtor can continue to 
perform the operation of a malfijnctioning section that has been taken offline. For 
example, if the accelerator 44 has an unused section, then the configuration 
manager $4 may configure this unused sectfon to perform the operation that was to 
be the malfunctioning section. If the accelerator 44 has no unused section, then the 
configuration manager 84 may reconfigure a sectton of the accelerator that currently 
perfonns a first operation to perform a second operation of, i.e., take over for. the 
maHunctloning section. This technique may be useful where the first operation can 
be omitted but the second operation cannot, or where the data-processing 
application 80 is more suited to perform the first operation than it is the second 
operation. This abtltfy to shift the performance of an operation from one section of 
the accelerator 44 to another section of the accelerator increases the flexibility, 
reliability, maintainability, and fault-tolerance of the peer-vector machine 40 (FIG. 3). 

J98| Referring to FIG- 7, the configuration manager 84 toads the firmware 

that defines the hard configuration of the accelerator 44 during Initialization of the 
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peer-vector machine 40 {FIG. 3), and, as disctissed above in conjunction with FIG. 6, 
may load firmware that redefines the hard configuration of the accelerator in 
response to an exception according to an embodiment of the invention. As 
discussed below, the configuration manager 84 often reduces the compiextty of 
5 designing and modifying the accelerator 44 and increases the fauit-toferance, 
reliabiiity, maintainability, and flexibility of the peer-vector machine 40 (FIG. 3). 

C993 During initialization of the peer-vector machine 40, the configuration 

manager B4 receives configuration data fhsm the accelerator configuration rogmtr^ 
70, and loads configuration fimiware identified by the configuration data. The 

10 configuration data are effectively instructions to the configuration manager B4 tor 
loading the firmware. For example, if a section of the initialized accelerator 44 
performs an FFT, then one designs the configuration data so that the firmware 
loaded by the manager 84 Implements an FFT In this section of the accelerator. . 
Consequently, one can modify the hard configuration of the accelerator 44 by merely 

1 6 generating or modifying the configuration data before initianzation of the peer-vector 
machine 40. Because generating and modifying the configuration data is often 
easier than generating and modifying the firmware directly — particularly if the 
configuration data can instruct the configuration manager 84 to load existing 
firmware from a library — the configuration manager 84 typically reduces the 
20 complexity of designing and modifying the accelerator 44, 

[1 001 Before the configuration manager 84 loads the flmiware Identified fay 

the configuration data, the configurafion manager determines whether the 
accelerator 44 can support the configuration defined by the configuration data. For 
example, If the configuration data instructs the configuration manager 84 to load 
25 firmware for a particular PLIC {not shown) of the accelerator 44, then the 

configuration manager a4confinns that the PLiC is present before loading the data. 
If the PLIC is not present, then the configuration manager 84 halts the initialization of 
the acceierator 44 and notifies an operator that the accelerator does not support the 
configuration. 

30 £1 01] After the configuration manager 84 confinjns that the accelerator 

supports the defined configuration, the configuration manager loads the firmware into 
the accelerator 44, which sets Its hard configuration with the firmware, e.g., by 

25 



wo 2004/042574 



FCr/US20«3/034559 



ioadfng the firmware into the firmware memory 52. Typlc^My, the configuration 
manager 84 sends the firmware to the accelerator 44 via one or mom channels i04i 
that are similar tn generation, structure, and operation to the channels 104 of FIG. 5. 
The configuration manager 84 may also receive data from the accelerator 44 via one 
or more channels 104a. For example, the accelerator 44 may send confirmation of 
the successful setting of its hard configuration to the configuration manager 84, 

i%Q2} After the hard conf^uratlon of the accelerator 44 is set, the 

configuration manager 84 may set tiie accelerator's hand configuration in response to 
an exception-handling instruction from the exception manager 84 as discussed 
above in conjunction with FIG. 6. In response to the exception-handling instaictlon, 
the configuration manager 84 downloads the appropriate configuration data from the 
r^istry 70, loads reconfiguration firmware Identified by the configuration data, and 
sends the firmware to the accelerator 44 via the channels 104f. The configuration 
manager 84 may receive confimiation of successful reconfiguration from the 
accelerator 44 via the channels 104^. As discussed above in conjunction with FIG. 
6, the configuration manager $4 may receive the exception-handling instruction 
directly from the exception manager 82 via the line 89 (FIG. 4) or indirectly via the 
channels 104cmi and 104cm2^ 

{1 03] The configuratbn manager 84 may also reconfigure the 

data-processing application 00 in response to an exceptton-handling Instruction from 
the exception manager 84 as discussed above in conjunction with FIG. 6. In 
response to the 6xceptlon4iandling instnactJon, the configuration manager 84 
instructs the data-processing application 80 to reconfigure Iteelf to perform an 
operation ttiat, due to malfunction or other reason, the accelerator 44 cannot 
perfontj. The configuration manager 84 may so instruct the data-processing 
application 80 directly via the line 87 (FIG. 4) or indirectly via channels 104api and 
104^2, and may receive infonuation from the data-processing application, such as 
confirmation of successful reconfiguration, directly or via another channel 104 (not 
shown). Alternatively, the exception manager 82 may send an exception-handling 
instruction to the data-processing 80, which reconfigures itself, thus tiypassing 8ie 
configuration manager 82. 
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C1041 Stili referring to FIG. 7, alternate embodiments of the configuration 

manager 82 are contemplated. For example, the configuration manager 82 may 
reconfigure the accelerator 44 or the data-processing application 80 for reasons 
other than the occurrence of an accelerator maif unction. 

5 [105] The precedtng discussion is presented to enabie a person skHfed In the 

art to make and use the invention. Various modifications to the embodiments will be 
readily apparent to those skiiled in the art, and the generic principles herein may be 
applied to other embodiments and applications without departing from the spirit and 
scope of the present invention. Thus, ttie present Invention is not intended to be 
10 limited to the embodiments shown, but is to be accorded the widest scope consistent 
with the principles and features disclosed herein. 
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WHAT iS CLAIMED IS: 

1 , A computing machine, compnsmg: 

a first buffer; 

a processor coypted to the buffer and operable to, 

execute an application, a first data-transfer object, and a second data- 
transfer object, 

publish data under tiie control of the application, 

load the published data into the bulfer under the control of the first 
data-transfer object, and 

retrieve the published data from the buffer under the control of the 
second data4ransfer object. 

2: The computing machine of claim 1 wherein the first and second data- 
transfer objects respectively comprise first and second instances of the same object 
code. 

3. The computing machine of claim 1 wherein the processor comiprises: 
a processing unit operable to execute the application and publish the data 
under the control of the application; and 

a data-transfer handier operable to execute the first and second data4ransfer 
objects, to load the published data into the buffer under the control of the first data- 
transfer object, and to retrieve the published data under the control of the second 
data-transfer object- 

4> The computing machine of claim 1 wherein the processor is further 
operable to execute a thread of the application and to publish the data under the 
control of the thread. 

5. The computing machine of claim 1 wherein the processor is further 
operable to: 

execute a queue object and a reader object; 
store a queue value under the control of the queue object, the queue 
value reflecting the loading of the published data into the buffer; 

read the queue value under the control of the mader object; 
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notify the second software object that the published data occupies ttie 
buffer under the controf of the reader ob|ect and in response to the queue vafue: and 

retrieve the pubifshed data from the storage iocatlon under the control 
of the second data-transfer object and in response to the notification. 

6. The computing machine of claim 1 , further comprising: 
a bus; and 

wherein the processor is operable to execute an communication object and to 
drive the retrieved data onto the bus under the control of the communication object. 

7. The computing machine of claim 1 , further comprising: 
a second buffer; and 

wherein the processor is operable to provide the retrieved data to the second 
buffer under the controi of the second data-transfer object 

8. The computing machine of cfafm 1 wherein the processor is further 
operable to generate a message that includes a header and the retrieved data under 
the control of the second data^transfer object 

9. The computing machine of claim 1 wherein: 

the first and second data-transfer objects raspectiVeiy comprise first and 
second instances of the same object code; and 

the processor Is operabie to execute an object factory and to generate the 
object code under the controf of the object factory. 

10> A computing machine, comprising: 
a first buffer; 

a processor coupled to the buffer and operable to, 

execute first and second data-transfer objects and an appflcation, 

retrieve data and load the r^rieved data into the buffer under the 
control of the first data-transfer object, 

unload the data fi^om the buffer under the control of the second data- 
transfer object, and 

process the unloaded data under the controi of the application. 
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1 1 . The computing machine of claim 1 0 wherein the first and second data- 
transfer objects respectively comprise first and second instances of the same object 
code, 

12. The oompyting machine of claim 10 wherein the processor comprises: 
e processing unit operable to execute the application and process the 

unloaded data under the control of the application; and 

a data-transfer handler operable to execute the first and second data-transfer 
objects, to retrieve the data from the bus and load the data into the buffer under the 
control of the first data-transfer object, and to unioad the data from the buffer under 
the control of the second data-transfer object 

1 3. The computing machine of claim 1 0 wherein the pnDcessor is further 
oparabie to execute a thread of the application and to process the unloaded data 
under the control of the thread, 

14. The computing machine of claim 10 wherein the processor is further 
operable to: 

execute a queue object and a reader object; 

store a queue value under the control of the queue object, the queue 
value reflecting the loading of the published data into the first buffen 

read the queue value under the control of the reader object; 

notify the second data4ransfer object that the pufoStehed data occupfas 
the buffer under the control of the reader object and in response to the queue value; 
and 

unload the pubiished data from the buffer under the oontroj of the 
second data-transfer object and in response to the notification. 

15. The computing machine of claim 10, further comprisfng: 
a second buter; and 

wherein the processor is operable to retrieve the data from the second buffer 
under the control of the first data4ransfer object 

1 6. The computing machine of claim 10, further comprising: 
a bus; and 
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wherein the processor is operate to execute an communicatfon object, to 
receive the data from the bus under the contra! of the communjcatlon object, and to 
retrieve the data from the communicatton object under the controi of the first data- 
transfer object 

17. The computing machine of cfaim 10 wherein: 

the first and second data-transfer objects respectively comprise first and 
second instances of the same object code; and 

the processor is operable to execute an object factory and to generate the 
object code under the controi of the object factory. 

18. TTie computing machine of cialm 10 wherein the processor is llirther 
operable to recover the data from a message that includes a header and the data 
under the controi of the first data-transfer object. 

19. A peer-vector machine, comprising: 
a buffer; 

a bus; 

a processor coupled to the buffer and to the bus and operable to, 

execute an application, first and second data-transfer objects, and an 
communication object, 

publish data under the control of the application, 
oad the published data Into the buffer under the control of the first data- 
transfer object, 

retrieve the published data from the buffer under the control of the 
second data-transfer object, and 

drive the published data onto the bus under the control of the 
communication object; and 

a pipeline acceierator coupled to the bus and operable to receive the 
published data from the bus and to process the received published data. 

20. The peer-vector machine of claim 1 9 wherein: 
the processor is further operable to construct a message that indudes the 
published data under the control of the second data-transfer object and to drive the 
message onto the bus under the controi of the communication object; and 
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the pipeline accelerator is operable to receive the message from the bus and 
to recover the published data from the message, 

21 . The peer-vector machine of ciaim 1 9, further comprising: 

a registry coupled to the host processor and operable to store object data; and 
wherein the processor is operable to, 
execute an object factory , and 

to generate the first and second data-transfer objects and the 
communication object from the object data under the control of the object factory. 

22. A peer-vector machine, comprismg: 
a buffer; 

a bus; 

a pipeilne accelerator coupled to the bus and operabie to generate data and 
to drive the data onto the bus; and 

a processor coupled to the buffer and to the bus and operabie to, 

execute an application, first and second data-transfer objects, and an 
communication object, 

receive the data from the bus under the central of the communication 

object, 

load the received data Into ttie buffer untier the controi of the first data- 
transfer object, 

unload the data from the buffer under the control of the second data- 
transfer object and 

process the unloaded data under the controf of the application. 

23. The peer^vector machine of claim 22 wherein: 

the pipeline accelerator is further operable to construct a message that 
inciudes the data and to drive the message onto the bus; and 

the processor Is operable to, 

receive the message from the bus under the control of the 
communication object, and 

recover the data from the message under the control of the first data- 
transfer object. 

24. The peer-vector machine of daim 22, further comprising: 
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a regisfty coupled to the host processor and operable to store object data; and 

wherein the processor is operable to, 

execute an object factory, and 

to generate the first and second data-transfer ot)|ects and the 
communication object from the object data under the controi of the object factory. 

25, A peer-vector machine, comprising: 
a first buffer; 

a bus; 

a processor coupled to the buffer and to the bus and operable to, 

execute a configuration manager, first and second data-transfer 
objects, and a communication object, 

load configuration firmware into the buffer under the control of the 

configuration manager and the first data-transfer ob|ect, 

ratriava the configuration firmware from the buffer under the control of 
the second data-transfer object, and 

drive the configuration firmware onto the bus under the control of the 
communication object; and 

a pipeline accelerator coupjed to the bus and operabie to receive the 
configuration firmware and to configure itself with the configumfion firmfware. 

26, The peer-vector machine of claim 25 wherein: 

the processor is further operable to constmct a message that includes the 
configuration firmware under the controi of the second data-transfer object and to 
drive the message onto the bus under the controi of the communication object; and 

the pipeiine acceierator is operable to receive the message from the bus and 
to recover the configuration firmware from the message, 

27. The peer-vector machine of claim 26, further comprising: 

a registry coupled to the processor and operable to store configuratfon data; 

and 

wherein the processor is operable to iocate the configuration firmware from 
the configuration data under the controi of the configuration manager, 

28. The peer-vector machine of daim 25, further comprising: 
a second buffer; and 
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wherein the processor 5s operabte to: 

execute an application and third and fourth data-transfer objects, 

generate a configuration instruction under the controt of the 
configuration manager, 

toad the configuration instruction into the second buffer under the 
control of the third dafa-transfer object, 

retrieve the configuration instruction from the second buffer under the 
control of the fourth data-transfer object, and 

configure the appHcation to perform an operation corresponding to the 
configuration instruction under the control of the appiicatlon. 

29. The peer-vector machine of clafm 25 wherein the processor is operable 

to: 

generate a configuration instructjon under the control of the configuration 
manager; and 

configure the applicatton to perform an operation corresponding to the 
configuration instruction under the controi of the appiication, 

30. The peer-vector machine of claim 25 wherein the configuration 
manager is operabte to confirm that the pipefine acceierator supports a configuration 
defined by the configuration data before loading the firmware. 

31 . A pear-vector machine, comprising: 
a first buffer; 

a bus; 

a pipeline acceierator coupled to the bus and operable to generate exception 
data and to drive the exception data onto the bus; and 

a processor coupled to the buffer and to the bus and operable to, 

execute an exception manager, first and second data-transfer objects, 
and an communication object, 

receive the exception data from the bus under the control of the 
communication object, 

load the received exception data into the buffer under the control of the 
first data-transfer object, 
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un ioad the exception data from the buffer under the control of the 
second data-transfer object, and 

process the unioaded exception data undBt the control of the exception 

manager. 

32, The peer-vector machine of cfaim 31 wherein: 

the pipeline Is further operable to construct a message that mcludes the 
exception data and to drive the message onto the bus; and 

the processor is operable to receive the message from the bus under the 
control of the communication object and to recover the exception data from the 
message under the control of the first data-transfer object 

33, The pear-vector machine of ciaim 31 , further comprising: 

a second buffer; 

wherein the proGessor is further operable to, 

execute a configuration manager and third and fourth data-transfer 

objects, 

generate configuratjon firmware under the contro! of the configuration 
manager m response to the exception data, 

load the configuration firmware into the second buffer under the control 
of the third data-transfer object, 

unload the configuration instruction from the second buffer under the 
controi of the fourth data-transfer object, and 

drive the configuration fimiware onto the bus under the control of the 
communication object; and 

wherein the pipeline accelerator is operable to receive the configuration 
fintiware from the bus and reconfigure itself with the firmware. 

34, The peer-vector machine of claim 31 wherein the processor is further 
operable to: 

execute an application and a configuration manager; 

generate a configuration instruction under the control of the configuration 
manager in response to the exception data; and 

reconfigure the applicetion under the control of the appflcation in response to 
the configuration instruction, 
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35. A peer-vector machine, comprising: 

a configuration registry operable to store configuration data; 

a processor coupled to the configuration registry and operable to locate 
configuration firmware from the configuration data; and 

a pipeline accelerator coupied to the procassor and operable to configure 
itself with the configy ration firmware. 

36- A peer-vector machine, comprising: 

a configuration registry operable to store configuration data; 

a pipeline acceterator; and 

a processor coupled to the configuration registry and to the pipeline 
accelerator and operable to retrieve configuration firmware in response to the 
configuratjon data and to configure the pipeline acceterator with the configuration 
firmware- 

37. A method, comprising: 
publishing data with an application; 

ioading the published data into a first buffer with a first data-transfer ob|ect; 

and 

retrieving the published data from the buffer with a second data-transfer 

object. 

38. The method of claim 37 wherein publishing the data comprises 
publishing the data with a thread of the appficetion. 

39. The method of claim 37, further comprising: 

generating a queue value that corresponds to the presence of the published 
data in the buffer; 

notifying the second data-transfer object that the pubiished data occupies the 
buffer in response to the queue value; and 

wherein retrieving the published data comprises retrieving the published data 
from the storage location with the second data-transfer object in response to the 
notification. 

40. The method of claim 37, further comprising driving the retrieved data 
onto a bus with a communication object 
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41 . The method of daim 37, further compnsing loading the retrieved data 
into a secx)nd buffer with the second data«transfer object, 

42. The method of daim 37, further comprising: 

generating a header for the retrieved data with the second data-transfer 
object; and 

combining the header and the retrieved data into a message with the second 
data-transfer object, 

43. The method of claim 37, further comprising: 
generating data-transfer object code with an object factory; 

generating the first data-transfer object as a first instance of the object code; 

and 

generating the second data-transfer object as a second instance of the object 

code, 

44. The mettiod of oiatm 37, further comprising receiving and processing 
the data from the second data-transfer object with a pipeiine accelerator, 

45. A method, comprising: 

retrieving data and foading the retrieved data into a first buffer with a first date- 
transfer object, 

unioading the data from the buffer with a second data-transfer object; and 
processing the unloaded data with an application. 

46. The method of claim 45 wherein processing the unloaded data 
comprises processing the unloaded data with a thread of the application- 

47. The method of claim 45, further comprising: 

generating a queue value that corresponds to the presence of the data 

in the buffer; 

notifying the second data4ransfer object that the data occupies the 
buffer in response to the queue value; and 

wherein untoading the data comprises unloading the data from the 
buffer with the first data-transfer object In response to the notification. 

48. The method of ciaim 45 wherein retrieving the data comprises 
retrieving the data from a second buffer with the first data-transfer object, 
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49. The method of claim 45, further comprising: 
receMng the data from a bus with an communication ob|ect; and 
wherein retrieving the data comprises retrieving the data from the 
communication object under with the first data-transfer object. 

50* The method of claim 45, further comprising providing the data to the 
first data-transfer object with a pipeline accelerator. 

51 . A method, comprising: 

pubfishing data with an appficatfon running on a processor; 
loading the published data into a buffer with a first data-transfer object ainning 
on the processor; 

retrieving the published data from the buffer with a second data-transfer object 
running on the processor; 

driving the retrieved published data onto a bus with an communication object 
running on the processor; and 

receiving the pubiished data from the bus and processing the published data 
with a pipeNne accelerator 

52, The method of claim 51 , further comprising: 

generating a message that indudes a header and the pubiished data with the 
second data-transfer object; 

wherein driving the data onto the bus comprises driving the message onto the 
bus with the communiGatlon object; and 

receiving and processing the pubiished data comprises receiving the message 
and recovering the pubiished data from the message with the pipeline acceierator. 

53, A method, comprising: 

generating data and driving the data onto a bus with a pipeilne acceierator; 
receiving the data from the bus with the communication object; 
loading the received data into a buffer under with a first data-transfer object; 
unloading the data from the buffer with a second data-transfer object; and 
processing the unioaded data with an application, 

54. The method of claim 53, further comprising: 
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wherein generating the data comprises constructing a message that indudes 
a header and the data with the pipeline accelerator; 

wherein driving the data oomprises driving the message onto the bus with the 
pipeline accslerator; 

wherem receiving the data oomprises receiving the message from the bus 
with the communication object; and 

recovering the data from the message with the first data-transfer object. 

56- A method, comprising: 

retrieving configuratfon flmnware with a configuration manager; 

loading the configuration firmware into a first buffer with a first communication 

object; 

retrieving the configuration firmware from the buffer with a second 
communication object; 

driving the configuration firmware onto a bus with an communication object; 
receiving the configyration firmware with a pipeline accelerator; and 
configuring the pipeline accelerator wtth the configuration firmware. 

56* The method of claim 55. further comprising: 
generating a configuration instruction with the configuration manager; and 
configuring the application to perform an operation corresponding to the 
configuration instruction. 

67. The method of ciaim 55, further comprising: 

generating a configuration instruction wfth the configuration manager; 

ioading the configuration instruction into a second buffer with a third 
communication object; 

retrieving the configuration instruction from the second buffer with a fouri;h 
communication object; and 

configuring the application to perform an operation corresponding to the 
configuration instruction. 

58, A method, comprising: 

generating exception data and driving the exception data onto a bus with a 
pipeline accelerator; 

receiving the exception data from the bus with a communication Dbject; 
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loading the received exception data into a buffer with a first data4ransfer 

object; 

unloading the exceptiorj data from the buffer with a second data-transfer 
object; and 

processing the unioaded exceptfon data under with an exception manager- 

59. The method of clainn 58, further comprising: 

retrieving configuration firmware with a configuration manager in response to 
the exception data, 

foading the conflguraflon firmware Into a second buffer with a third transfer 

object; 

unloading the configuration tnstaiction from the second bufler with a fourth 
data-transfer object; 

driving the configyration firmware onto the bus with the communication object; 

and 

fBConfiguring the pipeline accelerator with the con^guration firmware, 

60. The method of claim 58, fy rther comprising: 

generating a configuration instmction with a configuration manager in 
response to the error data; and 

reconfiguring the application in response to the configuration instruction, 

61 . A method, comprising: 

retrieving configuration fimiware pointed to by configuration data stored in a 
configuration registry during an initiaifeation of a computing machine; and 

configuring a pipeiine accaferator of the computing machine with the 
configuration firmware. 
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